HPAVC/HPAVC CD-ROM.iso/KAOS1_52.ZIP/KAOS1-52

Text File | 1993-06-13 | 32KB | 621 lines

Chaos Digest             Vendredi 11 Juin 1993        Volume 1 : Numero 52
                            ISSN  1244-4901

       Editeur: Jean-Bernard Condat ([e-mail])
       Archiviste: Yves-Marie Crabbe
       Co-Redacteurs: Arnaud Bigare, Stephane Briere

TABLE DES MATIERES, #1.52 (11 Juin 1993)
File 1--40H VMag Number 6 Volume 2 Issue 2 #00B-00C (reprint)
File 2--Fortress: services de securite europeens a la loupe (rapport)

Chaos Digest is a weekly electronic journal/newsletter. Subscriptions are
available at no cost by sending a message to:
                [e-mail]
with a mail header or first line containing the following informations:
                    X-Mn-Admin: join CHAOS_DIGEST

The editors may be contacted by voice ([phone]), fax [phone])
or S-mail at: Jean-Bernard Condat, Chaos Computer Club France [CCCF], B.P.
155, 93404 St-Ouen Cedex, France.  He is a member of the EICAR and EFF (#1299)
groups.

Issues of ChaosD can also be found from the ComNet in Luxembourg BBS (+352)
466893.  Back issues of ChaosD can be found on the Internet as part of the
Computer underground Digest archives. They're accessible using anonymous FTP:

        * kragar.eff.org [192.88.144.4] in /pub/cud/chaos
        * uglymouse.css.itd.umich.edu [141.211.182.53] in /pub/CuD/chaos
        * halcyon.com [192.135.191.2] in /pub/mirror/cud/chaos
        * ftp.cic.net [192.131.22.2] in /e-serials/alphabetic/c/chaos-digest
        * cs.ubc.ca [137.82.8.5] in /mirror3/EFF/cud/chaos
        * ftp.ee.mu.oz.au [128.250.77.2] in /pub/text/CuD/chaos
        * nic.funet.fi [128.214.6.100] in /pub/doc/cud/chaos
        * orchid.csv.warwick.ac.uk [137.205.192.5] in /pub/cud/chaos

CHAOS DIGEST is an open forum dedicated to sharing French information among
computerists and to the presentation and debate of diverse views. ChaosD
material may be reprinted for non-profit as long as the source is cited.
Some authors do copyright their material, and they should be contacted for
reprint permission.  Readers are encouraged to submit reasoned articles in
French, English or German languages relating to computer culture and
telecommunications.  Articles are preferred to short responses.  Please
avoid quoting previous posts unless absolutely necessary.

DISCLAIMER: The views represented herein do not necessarily represent
            the views of the moderators. Chaos Digest contributors
            assume all responsibility for ensuring that articles
            submitted do not violate copyright protections.

----------------------------------------------------------------------

Date: Tue May 11 09:24:40 PDT 1993
From: [e-mail] (American_Eagle_Publication_Inc. )
Subject: File 1--40H VMag Number 6 Volume 2 Issue 2 #00B-00C (reprint)


40Hex Number 6 Volume 2 Issue 2                                    File 00B

                      ++++++++++++++++++++++++++++++
                       SCAN STRINGS, HOW THEY WORK,
                           AND HOW TO AVOID THEM
                      ++++++++++++++++++++++++++++++
                               By Dark Angel
                      ++++++++++++++++++++++++++++++

Scan strings  are the  scourge of  the virus author and the friend of anti-
virus wanna-bes.   The  virus author  must find encryption techniques which
can successfully  evade easy detection.  This article will show you several
such techniques.

Scan strings,  as you  are well  aware, are  a collection of bytes which an
anti-viral product  uses to  identify a virus.  The important thing to keep
in mind  is that  these scan  strings represent  actual code  and can NEVER
contain code  which could occur in a "normal" program.  The trick is to use
this to your advantage.

When a  scanner checks  a file for a virus, it searches for the scan string
which could  be located  ANYWHERE IN  THE FILE.   The  scanner doesn't care
where it  is.   Thus, a  file which  consists solely of the scan string and
nothing else  would be  detected as  infected by  a virus.   A  scanner  is
basically  an   overblown  "hex  searcher"  looking  for  1000  signatures.
Interesting, but  there's not  much you  can do  to exploit this.  The only
thing you  can do  is to  write code so generic that it could be located in
any program  (by chance).   Try  creating a  file with  the following debug
script and  scanning it.   This  demonstrates the fact that the scan string
may be located at any position in the file.

---------------------------------------------------------------------------

n marauder.com
e 0100  E8 00 00 5E 81 EE 0E 01 E8 05 00 E9

rcx
000C
w
q

---------------------------------------------------------------------------

Although scanners  normally search  for decryption/encryption  routines, in
Marauder's case,  SCAN looks  for the  "setup" portion  of the  code,  i.e.
setting up  BP (to the "delta offset"), calling the decryption routine, and
finally jumping to program code.

What you  CAN do  is to  either minimise  the scannable code or to have the
code constantly  mutate into  something different.  The reasons are readily
apparent.

The simplest  technique is  having multiple  encryption engines.   A  virus
utilising this  technique has  a database  of encryption/decryption engines
and uses  a random  one each  time it infects.  For example, there could be
various forms  of XOR  encryption or  perhaps another  form of mathematical
encryption.   The trick  is to  simply replace  the code for the encryption
routine each time with the new encryption routine.

Mark Washburn  used this  in his  V2PX series of virii.  In it, he used six
different  encryption/decryption   algorithms,  and   some  mutations   are
impossible to detect with a mere scan string.  More on those later.

Recently, there  has been  talk of  the so-called  MTE, or mutating engine,
from Bulgaria  (where else?).   It  utilises the multiple encryption engine
technique.   Pogue Mahone  used the  MTE and it took McAfee several days to
find a  scan string.   Vesselin  Bontchev, the McAfee-wanna-be of Bulgaria,
marvelled the engineering of this engine.  It is distributed as an OBJ file
designed to  be able to be linked into any virus.  Supposedly, SCANV89 will
be able to detect any virus using the encryption engine, so it is worthless
except for  those who  have an  academic interest  in such matters (such as
virus authors).

However,  there   is  a  serious  limitation  to  the  multiple  encryption
technique, namely  that scan  strings may  still be  found.   However, scan
strings must  be isolated  for each  different encryption  mechanism.    An
additional  benefit   is  the   possibility  that  the  antivirus  software
developers will  miss some  of the  encryption mechanisms  so not  all  the
strains of the virus will be caught by the scanner.

Now we  get to  a much better (and sort of obvious) method: minimising scan
code length.   There are several viable techniques which may be used, but I
shall discuss but three of them.

The one  mentioned before which Mark Washburn used in V2P6 was interesting.
He first  filled the  space to  be filled  in with the encryption mechanism
with dummy  one byte  op-codes such  as CLC, STC, etc.  As you can see, the
flag manipulation  op-codes were  exploited.   Next, he randomly placed the
parts of  his encryption  mechanism in  parts of this buffer, i.e. the gaps
between the  "real" instructions were filled in with random dummy op-codes.
In this manner, no generic scan string could be located for this encryption
mechanism of  this virus.   However, the disadvantage of this method is the
sheer size of the code necessary to perform the encryption.

A second  method is  much simpler than this and possibly just as effective.
To minimise scan code length, all you have to do is change certain bytes at
various intervals.   The  best way  to do  this can  be explained  with the
following code fragment:

  mov si, 1234h                     ;Starting location of encryption
  mov cx, 1234h                     ;Virus size / 2 + variable number
loop_thing:
  xor word ptr cs:[si], 1234h       ;Decrypt the value
  add si, 2
  loop loop_thing

In this code fragment, all the values which can be changed are set to 1234h
for the  sake of  clarity.   Upon infection,  all you  have to do is to set
these variable  values to  whatever is  appropriate  for  the  file.    For
example, mov  bx, 1234h  would have  to be  changed to  have the encryption
start at the wherever the virus would be loaded into memory (huh?).  Ponder
this for  a few  moments and  all shall  become clear.   To  substitute new
values into the code, all you have to do is something akin to:

  mov [bp+scratch+1], cx

Where scratch is an instruction.  The exact value to add to scratch depends
on the  coding of  the op-code.   Some  op-codes take their argument as the
second byte,  others take  the  third.    Regardless,  it  will  take  some
tinkering before it is perfect.  In the above case, the "permanent" code is
limited to  under five or six bytes.  Additionally, these five or six bytes
could theoretically  occur in  ANY PROGRAM  WHATSOEVER, so  it would not be
prudent for  scanners to search for these strings.  However, scanners often
use scan  strings with wild-card-ish scan string characters, so it is still
possible for a scan string to be found.

The important  thing to  keep in  mind when using this method is that it is
best for  the virus  to use separate encryption and decryption engines.  In
this manner, shorter decryption routines may be found and thus shorter scan
strings will  be needed.   In  any  case,  using  separate  encryption  and
decryption engines increases the size of the code by at most 50 bytes.

The last method detailed is theft of decryption engines.  Several shareware
products utilise  decryption engines  in their  programs to  prevent simple
"cracks" of  their products.   This  is, of  course, not a deterrent to any
programmer worth  his salt,  but it  is useful  for virus  authors.  If you
combine the  method above  with  this  technique,  the  scan  string  would
identify the  product as  being infected with the virus, which is a) bad PR
for the company and b) unsuitable for use as a scan string.  This technique
requires virtually  no effort,  as the decryption engine is already written
for you by some unsuspecting PD programmer.

All the  methods described  are viable  scan  string  avoidance  techniques
suitable for  use in  any virus.   After  a few practice tries, scan string
avoidance should  become  second  nature  and  will  help  tremendously  in
prolonging the effective life of your virus in the wild.

+++++

40Hex Number 6 Volume 2 Issue 2                                     File 00C

                        ++++++++++++++++++++++++
                             Virus Contest!
                           'The Spammies(tm)'
                        ++++++++++++++++++++++++
                        Deadline: July 4th, 1992


   This is the first PHALCON/SKISM virus contest.  As a matter of fact, this
is the first contest of its kind.  We believe that it will motivate you to
produce more original code, rather than more hacks.  Winners may have already
won $10,000,000, as well as the prestige of winning the first ever 'Spammie'
awards.


Rules and Regulations:
1)  All submissions must be original source code. (no hacks)
2)  Only one submission is allowed per programmer, plus one group project.
3)  All viruses must be recieved by us before July 4th, 1992.
4)  Viruses must be accompanied by a complete entry form. (see below)
5)  The original, compilable, commented source MUST be included, along with an
    installer program, or a dropper, in the case of boot block viruses.
6)  Entries must include a location where the author may be contacted, such as
    an email address or a BBS.
7)  Personnel or persons related to personnel of PHALCON/SKISM are not
    eligable.
8)  The source must compile without error under Tasm or Masm (please specify
    what assembler and version you used, along with the necessary command line
    switches).  If we cannot compile your virus, it will be disqualified.
9)  All entries recieve a free subscription to 40hex.  (hehehehe)
10) The entry must be uploaded privately to the sysop, stating that it is a
    contest entry.
11) The viruses must not be detectable by the current version (as of July 4th)
    of any known virus scanner.
12) Viruses will be judged by our 'panel of experts' in three catagories.
    6.1)  Stealth
    6.2)  Size
    6.3)  Reproductivity
    6.4)  Performance
        For example, Red Cross is an example of a 'high performance' virus.
        It was entertaining and well done.

*** Entry Form

Handle ________________________
Group Afiliation ______________
Virus Name ____________________
Size ____bytes (if you need more spaces, go away)
Type               ___ File Infector ___ Boot block
Infection method   ___ Direct Action ___ Memory Resident   ___ Directory chain
                   ___ Other (please describe it in detail)
Encryption routine ___ None (bah)    ___ Xor loop
                   ___ Other (please describe it in detail)

Describe what makes your infection routine unique.
_____________________________________________________________________________
_____________________________________________________________________________
Describe what makes your encryption routine unique.
_____________________________________________________________________________
_____________________________________________________________________________
Describe what means your virus uses, other than encryption, to keep itself
hidden.
_____________________________________________________________________________
_____________________________________________________________________________
What is the largest possible scan string for this virus?  __bytes

What else sets this virus apart from other viruses?
_____________________________________________________________________________
_____________________________________________________________________________
_____________________________________________________________________________

------------------------------

Date: Fri Jun 11 15:02:53 BST 1993
From: internet!baltimore.ie!susan (Susan Barry )
Subject: File 2--Fortress: services de securite europeens a la loupe (rapport)


                  IMPLEMENTING AND PROVING SECURITY
               SERVICES FOR THE RARE/COSINE COMMUNITY

    Susan Barry, Patricia McQuillan, Michael Purser (Baltimore Technologies)
               Jonathan Moffett  (University of York)


Summary
+-------

Secure electronic-mail (PEM) and remote access services, using asymmetric key
cryptology have been developed and proved between  several European countries.
The paper reviews the project; high-lighting its shortcomings, since they are
most likely to be of interest to others.

1. Introduction
+---------------

The COSINE Sub-Project P8 (now named "FORTRESS") provides secure electronic
mail (Privacy Enhanced Mail: PEM) and remote access services over wide area
networks using asymmetric key cryptology.  Its main features have been
described in a previous paper [1].  The design phase lasted from November
1991 until April 1992, and the implementation terminated in October 1992 with
the installation of systems in six different countries.  From then until March
1993 evaluation and proving of FORTRESS took place.  This paper is largely
concerned with this latter aspect of the project.  However it is necessary
to review the security services provided if the evaluation and proving are
to be meaningful.  This is done in Section 2.  Sections 3 and 4 are critiques
of the user-related and technical aspects of the services.  Section 5
describes the proving process, and Section 6 contains brief conclusions.

2. Security Service Overview
+----------------------------

The principal service provided is secure messaging based on PEM [2].  Messages
may be guaranteed as uncorrupted and authentic by attaching the sender's
digital signature to them; and may be made confidential by means of encryption
Public key cryptology (RSA) [3], is used for the signatures, and for
encrypting the symmetric keys which in turn are used to encrypt (DES) [4] the
message text.  The use of public key cryptology implies the existence of a
Certification Authority (CA) which issues certificates guaranteeing the
genuineness of users' public keys.  (This is done by having the CA sign the
user's identity and public key as a unit.)  In FORTRESS the CA, operated in
Dublin by Baltimore Technologies, generates as well as certifies users' secret
and public keys.  New users are "recommended" by existing privileged users,
called Security Administrators (SAs); and this is an on-line operation between
the SA's system and the CA over the network.This remote access to the CA is
made secure by means of a two-way X.509 strong authentication procedure [5],
in which both parties are reciprocally and securely identified, and during
which a symmetric key is established for stream-encrypting the subsequent
dialogue using BSA [6].

In response to a successful Recommendation an SA receives, on behalf of the
new user, a Personal Secure Environment (PSE) encrypted under  a DES-key,
derived from a PIN via a one-way function.  This PIN is itself submitted,
encrypted, in the prior recommendation.  The PSE  contains the user's secret
key and other cryptographic data.  It is a  local matter as to how this PSE
is made available to the new user; but  once this has been achieved he can
perform signing/authentication and encryption/decryption operations for PEM
and access to the CA, by entering his PIN as required to decrypt (momentarily)
his PSE.  Naturally, the user's first operation on receiving a PSE will be to
change the PIN.

In addition to Recommendations, other applications at the CA are made
available to users over the secure remote access service.  For example an
SA can revoke a certificate, and place it on a blacklist.  Revocation would
apply if the certificate owner's secret key were compromised, or if the owner
were no longer considered to be a suitable system user.  Ordinary users can
also access the blacklist on the CA, to read it or download it.  They can
download the database of valid certificates.  They can access news files, etc.

To enable the CA to distinguish between ordinary and privileged users (SAs),
a user's authorisation attributes are built into his certificate.  (Other
information, such as an expiry date for its validity, is also built into
the certificate.)  The CA uses these attributes to control Recommendations,
Revocations and other operations according to an authorisation hierarchy.
For example, only certain SAs can recommend new SAs at a new user site; SAs
in one country cannot revoke users in another; etc.  However, the presence
of authorisation attributes in the certificate (a necessary concept borrowed
from architectures such as Kerberos [7], SESAME [8]) causes a FORTRESS
certificate to be non-standard; i.e. not compatible with X.509.  (There are
plans to overcome this problem, maintaining FORTRESS certificates for use
with remote access, but introducing further X.509-compatible certificates
to allow interworking with other systems, e.g. the "Password" project.)
At the CA, there are additional functions which enable operators to generate
RSA keys, maintain the database and blacklist, etc.  The access of operators
to the CA is controlled by smart cards.

GMD's SecuDe software was used as a basis for the development of the FORTRESS
software; in particular, it provided the PEM implementation, and the basic
functions of the CA.  The associated user interfaces, and the software for
the secure remote access service, have been developed by Baltimore.  The
systems run under Unix, on SUN workstations.  The remote access to the CA
is over X.25 networks.

3. User Aspects - a Critique
+----------------------------

Most of the problems in FORTRESS were related to the user's view and
management of the system.

The CA and its applications, accessed over the secure remote access
service, are merely security infrastructure for PEM - or possibly some
other future applications such as secure file transfer or EDI.  PEM
itself consists of two services : PEM-SCAN (process a received PEM
message) and PEM-CREATE (or generate a PEM message).  These services
are essentially file-to-file processors, which perform the
cryptographic functions on the way.  They are simple to use, but they
are not integrated with any mail or messaging system; principally
because too many differing mail systems, not to mention user
interfaces, exist amongst project participants.  Thus a sender of a
PEM message first creates the message; then processes it with PEM-
CREATE; and finally uses his normal mail service to transmit the file
created by PEM-CREATE.  This is inconvenient for users.
The security of the users' end-systems, although it is explicitly
outside the scope of the project, is however another practical
limitation on the service.  Apart from the user's encrypted PSE there
is no other project-provided protection of his system.  In particular,
the genuineness of the code is not checked; and there is no secure
control of local access (e.g. over a LAN) to the system.  Thus a user,
accessing his PEM facility, very probably not only sends his User-ID
and Password in clear over the LAN, but also his PSE PIN.  In reality,
if a user is to have confidence in the security of the PEM service, it
is necessary to install the end-system in a secure environment with
controlled access.

The decision to provide on-line access to the CA is, we believe, a
good one.  But it does imply that the CA should provide fast response.
This is not always the case.  Firstly, Recommendations give rise to
the generation of RSA keys, which may take many seconds - indeed more
than a minute.  A solution to this can be provided by pre-generating
keys, and holding them in a cache; although there are obvious security
risks with this approach.  Secondly, on-line user operations involving
the data base of extant and the blacklist of withdrawn certificates
can become quite lengthy if those lists are large.  Some conventional
data processing techniques (sorting!) could have been profitably used
in the FORTRESS project.

The project was conceived with a single CA serving many participants
in many countries, with secure remote access to the CA over X.25.
This gives rise to many anomalies.  For example, whereas participants
may have local security policies, procedures, etc.; the CA (whose
security is fundamental to all services) is not subject to those
policies.  There are questions about who is responsible for handling
security incidents.  There must be questions in participants' minds as
to how secure the CA really is.  In reality, serious users wish to
operate their own CAs for secure internal traffic.  Insofar as they
require secure external communication services; these could be
supported by the cross-certification of CAs' public keys, enabling a
user in one domain to authenticate a certificate belonging to a user
in another domain.  In turn, if CAs are to be local, it might be wiser
to have them operate over a LAN-compatible infrastructure; rather than
over X.25.

In an operational environment, as opposed to FORTRESS' pilot service,
another problem affecting users is that of out-of-date certificates.
In principle, a signature to a document is valid long after the
signatory's secret key has expired; provided that the signature was
generated before the expiry.  Similarly, a message may be held in
encrypted form for years; and the public key required to decrypt it
should be still available, even if withdrawn.  There is a need for a
service making available out-of-date certificates to users, which has
not yet been addressed in FORTRESS.

The above problem areas:

* PEM integration with the user's preferred mail environment
* Security of users' end-systems
* On-line response delays at the CA
* In-house versus external CA
* The availability of expired certificates to users have been identified
  by FORTRESS participants and the development team as important.
* Designers and implementors of future systems are advised to take note!

4. Technical Aspects - the Critique continues
+---------------------------------------------

The FORTRESS security services work well and effectively; but there is
room for improvement.  In addition to aspects visible to users (see
above) there are technical problem areas visible only to system
operators, or to software specialists.  Some of these are now
presented.

The initialisation of security systems usually requires manual or
semi-manual procedures for the distribution of first-time keys, PINs,
etc.  Similarly, reinitialisation (e.g. when a key is compromised)
will need such procedures, which may indeed be more demanding.  As an
example, if a new public key for the CA is to replace the old one,
because the old one can no longer be trusted, a major logistical
problem arises since all systems are affected.  The solutions to these
initialisation problems need to be carefully specified in advance; not
left to improvisation - possibly in panic conditions.

The identification of persons and systems is always more complex than
it appears.  FORTRESS' SecuDe uses serial numbers as unique
identifiers of certificates (per issuer).  But users refer to a
certificate by its owner's name.  The maintenance of an unambiguous
mapping between the two - given that users may have more than one
certificate, may be Revoked and re-Recommended several times, etc. -
is a potential source of problems.  Additionally, how is the integrity
of this serial number within the certificate-generating software
assured?  What form should the user's name take?  The PEM naming
hierarchy does not recognize the existence of a supranational entity
such as COSINE (or Europe) within which countries in the X.500 name
structure can fit.

The FORTRESS CA is operated by the system developers, Baltimore
Technologies.  It is a PIN-controlled application accessed from Unix.
This situation should be reversed.  The CA should be the main program
(PIN-controlled), with escape to Unix barred unless the operator has
special privileges.  The PIN itself is read from a chipcard; but it is
inserted into the chipcard "manually".  A rigorous separation between
development and operation is required, in which developers hand over
to operators a system (such as the CA) in which the operator's
capabilities are defined and restricted.  If this hand-over is
accepted the operator can thereafter be made accountable for the
system.

Users of the systems must trust the correctness of the software.  But
in security systems there is ample scope for "spoof" software, which
(for example) states that a signature has been authenticated
correctly, a remote system has been identified securely, or a text has
been encrypted, when it has not.  Spoof software can trick users into
entering their PINs to it, or into performing one operation
(Revocation) when another was intended (Recommendation).  Really
secure software should be encrypted on file, integrity checked on
loading; backups should be integrity checked and encrypted; etc.
FORTRESS does not do this.

However cryptographic keys are secured (e.g. in encrypted PSEs for
FORTRESS) there comes a time when they are used.  Unless this is done
within tamper-proof hardware, they are then at risk.  Spoof software
(see above) can capture them.  More prosaically, a user may simply be
diverted half-way through such a critical operation - and the key left
unprotected in memory.  Timeouts and memory clean-up facilities are
needed to minimise such risks.  FORTRESS employs timeouts, but
systematic clearing of memory after use is not practised.

In addition to the above problem areas there are several other
vulnerabilities in the FORTRESS implementation; ranging from basic
design problems (such as one PSE for the CA and all its operators) to
omissions (such as proper purging facilities, e.g. for the certificate
blacklist) due to time constraints and the limited scale of the
project.  Most of these however are minor, and too particular to
FORTRESS to be worth detailing here.

5. The Proving Process
+----------------------

The points made in Sections 3 and 4 were identified in the course of
the proving phase.

The COSINE Project Management Unit, right from the start, regarded the
testing out of the effectiveness of the security services as an
integral part of the sub-project, and planned and budgeted for this
activity.  Budgetary constraints meant that it was not possible to
bring in independent consultants to perform the entire proving
activity, because of the amount of time which would have been required
for familiarisation with the details of the system.  Therefore the
paper analysis and computer-based attacks were undertaken by the
developers, supervised by an independent consultant.

A systematic proving process was planned, involving both developers
and users.  It included :

* The regular exchange of valid and deliberately corrupted PEM messages
  between participants over a 3-month period, according to a weekly
  rota.  These exchanges revealed much about "user-friendliness", and
  the reliability of the underlying E-Mail carriers, but no occurrences
  of security failures were recorded.

* A "paper" analysis of the systems implemented which culminated in a
  list of some 60 potential vulnerabilities; the most important of which
  have been discussed above.

* Computer-based attacks on the security mechanisms, using defective
  certificates, weak keys, etc.  These attacks were designed to probe
  further the vulnerabilities identified in the paper analysis.  In
  reality, while interesting, they yielded no unforeseen results.

Conclusion
+----------

The proving activity in the project has served two useful purposes:

It has ensured that a number of weaknesses, already known to the
developers, were collected and evaluated in a methodical fashion.
The systematic computer-based attacks, which revealed no further
significant weaknesses, gave additional confidence in the robustness
of the system.

The FORTRESS systems and software have proved to be remarkably secure
and robust, given their pilot nature.  The weaknesses which have been
identified are almost all in the "environment" - the physical, network
and organisational surroundings within which FORTRESS operates.

Genuine FORTRESS problems are few, and essentially easily remedied.
More generally, in retrospect it is clear that although the
international "community" approach was necessary under COSINE, the
requirement for operational security services is nearly always
internal - within an organisation.  The FORTRESS products need to be
adapted to this requirement (e.g. a foolproof CA); and real user
groups (generally administrative not technical persons) need to be
prepared to receive them.

This is the intended next phase of the project.

Acknowledgements
+----------------

It is a pleasure to acknowledge the cooperation received by all
participants in the project; and the support and guidance given by the
COSINE Project Management Unit; in particular Maria Pallares.

References
+----------

1. "COSINE Sub-Project P8 : security services" Purser, Computer
   Networks and ISDN Systems 25 (1992) 476-482, North Holland.
2. "Privacy Enhanced Mail" RFC 1113, 1114, 1115 Internet.
3. "A method for obtaining digital signatures and public key
   cryptosystems" Rivest, Shamir and Adleman.  Comm. ACM 21 (1978).
4. "Data Encryption Algorithm" ANSI X3.92.
5. "The Directory - Authentication Framework" CCITT (Blue Book)
   Fascicle VIII.8 X.509 (1988).
6. "A fast stream encryptor" Purser, unpublished.
7. "The Kerberos Network Authentication Service Overview" MIT
   Project Athena RFC, Draft 1, April 1989.
8. "SESAME (Secure European System for applications in a Multivendor
   Environment) - An Introduction".  (Bull/ICL/SNI) Tom Parker, ICL
   Secure Systems.

------------------------------

End of Chaos Digest #1.52
************************************